Stack Using Two Queues
Push complexity: O(n).
Pop complexity: O(1).
Peek complexity: O(1).
Auxiliary space: O(n).
The alternative design can make Push O(1) and Pop O(n), depending on the desired workload.
We are building a simple undo-redo feature for a text editor. Our underlying messaging library only provides standard FIFO queues. How would you structure your push and pop operations using two of these queues to ensure the last action is undone first?
Imagine you implemented a LIFO stack using two FIFO queues where the push operation is expensive (O(N)) and pop is cheap (O(1)). During a code review, a teammate suggests swapping this so push is O(1) and pop is O(N). What happens to our application's latency profile if our workload is 90% writes (pushes) and 10% reads (pops)?
We're integrating with a legacy third-party event streaming service that only guarantees FIFO delivery. However, our local processing engine needs to process the most recent events first (LIFO) to handle state overrides. If we use two FIFO buffers to simulate this LIFO behavior, how would you design the system to minimize memory overhead and avoid copying data back and forth constantly?
You've implemented a thread-safe LIFO buffer using two FIFO message queues. Under high concurrent load, you notice that some 'pop' operations are returning elements out of order or throwing null pointer exceptions. Where are the race conditions likely occurring when we shift elements between the two queues, and how would you lock this down?
We are designing a distributed task execution engine. The underlying message broker (like AWS SQS) only supports FIFO queues, but we have a critical requirement to support priority preemption where the latest submitted high-priority task runs first (LIFO). If we simulate this using two FIFO queues per worker, what are the implications on network I/O, message duplication, and visibility timeouts when shifting messages between queues?
In an embedded system with highly constrained memory, we need to implement a call stack tracer using two pre-allocated FIFO ring buffers. Since we cannot dynamically resize these buffers, how do you handle buffer overflow conditions during a deep recursive call, and how do you optimize the element-copying overhead to prevent CPU spikes?